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ABSTRACT 



A method and system for providing a device identification 
mechanism within a consumer electronics based audio/video 
network. Several consumer electronics products, e.g., 
television, VCR, tuner, set-top box (e.g., intelligent receiver/ 
decoder, IRD), DVTRs, PCs, DVD players (digital video 
disk), etc., can be coupled within the network to communi- 
cate together via a standard bus (e.g., IEEE 1394 serial 
communication bus). In one embodiment, the HAVI network 
offers unique advantages consumer electronic vendors 
because the architecture offers for the home network many 
of the advantages of existing computer system networks. 
Specifically, interconnected devices can share resources and 
provide open, well defined APIs that allow ease of devel- 
opment for third party developers. The present invention 
provides a mechanism whereby a global unique identifier 
(GUID) is associated with each device of the HAVI network. 
Alow level driver constructs a GUID list of each device on 
the HAVI network. The order of. the GUID entries in the 
GUID list (e.g., the index) matches the physical identifiers 
assigned to the devices by the 1394 serial bus. Although the 
physical identifiers can change on bus reset, the GUID 
values are constant and are used for device communication. 
Speed map and topology map information is maintained 
based on the physical identifier information and therefore 
translations between GUIDs and physical identifiers are 
efficiently performed by the present invention when refer- 
encing speed map and topology information for an applica- 
tion. 

22 Claims, 26 Drawing Sheets 
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METHOD AND SYSTEM FOR PROVIDING A 
DEVICE IDENTIFICATION MECHANISM 
WITHIN A CONSUMER AUDIO/VIDEO 
NETWORK 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of communica- 
tion systems. More specifically, the present invention relates 
to equipment for home audio/video electronics. 

2. Related Art 

A typical home audiovisual equipment complement 
includes a number of components, e.g., a radio receiver, a 
CD player, a pair of speakers, a television, a VCR, a tape 
deck, etc. Components are connected to each other via sets 
of wires. One component is usually the central component of 
the home audiovisual system. This is usually the radio 
receiver, or the tuner/decoder. The control buttons and 
control switches are usually located on the front of the tuner 
and in many cases, some or all of these buttons and switches 
are duplicated on a hand held remote control unit. A user 
controls the home equipment by manipulating the buttons 
and switches on the front of the tuner, or alternatively, 
manipulating buttons on the hand held remote control unit. 

As consumer electronic devices have become more 
capable and more complex, demand for the latest and most 
capable devices has increased. As new devices emerge and 
become popular, new devices are purchased by consumers 
and "plugged" into their home audiovisual systems. The new 
device is simply plugged into the system alongside the 
pre-existing, older devices (e.g., cassette tape deck, CD 
player, and the like). The new device is plugged into an open 
input on the back of the tuner, or some other device coupled 
to the tuner. The consumer (e.g., the user) controls the new 
device via control switches on the new device itself, or via 
a separate remote control unit for the new device. 

As the number of new consumer electronics devices for 
the home audiovisual system has grown and as the sophis- 
tication and capabilities of these devices have increased, a 
number of problems with the conventional paradigm 
emerge. One such problem is incompatibility between 
devices in the home audiovisual system. In addition, where 
one device is much newer than another device additional 
incompatibilities may exist. For example, a new device 
might incorporate hardware (e.g., specific inputs and 
outputs) which enables more sophisticated remote control 
functions. This hardware may be unusable with older 
devices within the system. Another problem is the lack of 
functional support for differing devices within an audiovi- 
sual system. For example, even though a television may 
support advanced sound formats (e.g., surround sound, 
stereo, etc.), if an older less capable tuner does not support 
such functionality, the benefits of the advanced sound for- 
mats can be lost. Another problem is the proliferation of 
controls for the new and differing devices within the home 
audiovisual system. Each new device coupled to the audio- 
visual system often leads to another dedicated remote con- 
trol unit for the user to keep track of and learn to operate. 

In view of the above, it is desired to provide a commu- 
nication architecture in which consumer electronics devices 
can be integrated. In so doing, the consumer electronics 
devices can offer and be expanded to include advanced 
communications and control functionality between them- 
selves not heretofore offered. Within such communication 
architecture integrating consumer electronic devices ("a 
consumer's electronics network"), devices can communi- 
cate with each other and control one another. 



18,625 

2 

The IEEE 1394 serial communication bus, according to 
the IEEE 1394 standard, assigns a 6-bit physical identifier 
value (phy_id) to each device connected to the bus. The 
IEEE 1394 serial communication bus uses this physical 

S identifier to communicate with a device coupled thereto. 
Whenever a new device is inserted onto the bus, or an 
existing device is removed from the bus, or both, a bus reset 
is caused. The bus reset initiates certain well known bus 
recovery communications and functions in accordance with 

10 the IEEE 1394 standard, including the possible renumbering 
of the physical identifiers of the devices remaining on the 
IEEE 1394 bus. That is to say, the physical identifiers 
assigned to devices on the IEEE 1394 bus are not persistent. 
However, it is also desired within the consumer electron- 

15 ics network that high level applications adopt abstract and 
persistent identifiers for devices coupled to the IEEE 1394 
communication bus. Since many data structures (e.g., speed 
map and topology map) and communications channels are 
maintained and implemented within the IEEE 1394 standard 

20 using physical identifiers, a problem exists for high level 
applications that use a persistent identifier for each device 
but need to communicate with devices and/or require speed 
map and topology map information. What is needed is a 
mechanism and method operable within a consumer elec- 

25 tronic network that provides an IEEE 1394 communication 
framework, but also provides high level applications with a 
persistent identifier for devices coupled to the network. 
What is desired further is an efficient mechanism operable 
within a consumer electronic network that provides an IEEE 

30 1394 communication framework, but also provides high 
level applications with a persistent identifier for devices 
coupled to the network. 

SUMMARY OF THE INVENTION 

35 Accordingly, the present invention provides an efficient 
mechanism and method operable within a consumer elec- 
tronic network that provides an IEEE 1394 communication 
framework and also provides high level applications with a 
persistent identifier for devices coupled to the network. The 

40 present invention provides such advantageous functionality 
utilizing global unique identifiers (GUIDs) assigned to each 
device of the consumer electronics network. A GUID map is 
constructed and maintained upon each bus reset that maps 
GUID values with physical identifier values. These and 

45 other advantages of the present invention not specifically 
mentioned above will become clear within discussions of the 
present invention presented herein. 

A method and system are described herein for providing 
a device identification mechanism within a consumer elec- 

50 tronics based audio/video network. Within the network, 
several consumer electronics products, e.g., television, 
VCR, tuner, set-top box (e.g., intelligent receiver/decoder, 
IRD), DVTRs, PCs, DVD players (digital video disk), etc., 
can be coupled to communicate together via a standard bus 

55 (e.g., IEEE 1394 serial communication bus). This allows 
devices of the network to control one another and obtain 
information regarding one another. In one embodiment, the 
communication architecture used is the home audio/visual 
initiative (HAVI) format. The HAVI network offers unique 

60 advantages consumer electronic vendors because the archi- 
tecture offers for the home network many of the advantages 
of existing computer system networks, namely, intercon- 
nected devices can share resources and provide open, well 
defined APIs that allow ease of development for third party 

65 developers. HAVI offers extended interoperability. 

The present invention provides a mechanism whereby a 
global unique identifier (GUID) is associated with each 



03/26/2004, EAST Version: 1.4.1 



6,038,1 

3 

device of the HAVI network. A low level driver, a link 
driver, constructs a GUID list including a GUID for each 
device on the HAVI network. The order of the GUID entries 
in the GUID list (e.g., the index) matches the physical 
identifiers assigned to the devices by the IEEE 1394 serial s 
bus. Although the physical identifiers can become reas- 
signed on bus reset, the GUID values are constant. Within 
the present invention, network-based applications use a 
device's GUID to communicate therewith. Speed map and 
topology map information is maintained based on the physi- 5 q 
cal identifier information. Therefore translations between 
GUIDs and physical identifiers are efficiently performed by 
the present invention and are used for referencing speed map 
and topology information for an application program or 
other object. !5 

The 1394 local bus architecture creates a dynamic net- 
work within which a 1394 capable device can be inserted 
(e.g., hot insertion) at any time and be ready for use. Within 
the local bus system, a device is identified with a 6-bit 
physical identification number (phy_id) which is assigned 20 
by the local bus upon a bus reset. The phy_jd for a device 
can change as new devices are added into or existing devices 
are removed from the network. To provide higher level 
applications with a persisting identifier for a given device, 
the GUID (global unique identifier) is employed by the 25 
present invention. The GUID is a unique 64 bit value that 
contains a vender identification number coupled with a chip 
series identification number. The GUID is determined 
(according to IEEE 1212 standards) when an IEEE 1394 
capable device is manufactured. Because some bus 30 
information, such as speed map and topology map, are 
referenced by physical identifier values, the present inven- 
tion provides an efficient mechanism for presenting speed 
map and topology map information with respect to the 
corresponding GUID value for a device. 35 

A list of available devices in the network is information 
that network-based applications generally request periodi- 
cally. The present invention generates and maintains a GUID 
list of all devices of the network and orders the GUIDs of the 
GUID list by their respective physical identifier values. In 40 
this manner, the index of a particular GUID within the GUID 
list is its physical identifier and this index can be obtained 
and then used to access data from the speed map and 
topology map data structures which are constructed and 
maintained with respect to physical identifier values. For 45 
instance, if the speed between devicex (GUID1) and devicey 
(GUID2) is needed, the present invention locates the index 
values, index 1 and index2, for GUID1 and GUID2 using the 
GUID list. Index 1 and index2 are then used to access the 
speed map data structure and the desired speed data is 50 
returned to higher level applications. Alternatively, the entire 
speed map or topology map can be presented to the higher 
level application along with the current GUID list and the 
application can perform the indexing for the desired data, 

BRIEF DESCRIPTION OF THE DRAWINGS 55 

FIG. 1 A illustrates a physical port connection topology of 
an exemplary device configuration of the home audio/visual 
initiative (HAVI) consumer electronics network in accor- 
dance with the present invention. 60 

FIG. IB illustrates a local bus connection topology of the 
exemplary device configuration illustrated in FIG. 1A in 
accordance with the present invention. 

FIG. 1C illustrates a communication channel topology 
with respect to once device coupled to the HAVI network 65 
illustrated in FIG. 1A in accordance with the present inven- 
tion. 
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FIG. 2 illustrates internal circuitry of an intelligent 
receiver/decoder device of the HAVI network of FIG. 1A 
(acting as a full audio/visual, FAV, node) in accordance with 
the present invention. 

FIG. 3 illustrates a complement of software services made 
available by a full audio/visual (FAV) node of the HAVI 
network in accordance with the present invention. 

FIG. 4 illustrates communication pathways within the 
HAVI software architecture in accordance with the present 
invention. 

FIG. 5A illustrates communication flow to the communi- 
cation media manager (CMM) of the present invention from 
various software objects. 

FIG. 5B illustrates communication flow to various soft- 
ware objects from the communication media manager 
(CMM) of the present invention, 

FIG. 6 illustrates the IEEE 1394 local bus interface (e.g., 
MPEG/MV Link) with CMM in the HAVI architecture. 

FIG. 7A and FIG. 7B illustrates steps performed within 
the HAVI architecture to implement message communica- 
tion between devices. 

FIG. 8 illustrates communication pathways between an 
application, a device control module (DCM), the CMM and 
a link driver in accordance with the present invention. 

FIG. 9A is an illustration of a physical identifier indexed 
topology map data structure used by the present invention. 

FIG. 9B and FIG. 9C illustrate, respectively, one dimen- 
sional and two dimensional physical identifier indexed speed 
map data structures as used by the present invention, 

FIG. 10 A shows a first exemplary device network con- 
figuration within the HAVI architecture. 

FIG. 10B shows a second exemplary device network 
configuration within the HAVI architecture. 

FIG. 11A illustrates a GUID list as constructed by one 
embodiment of the present invention for the first exemplary 
device network configuration of FIG. 10A. 

FIG. 11B illustrates a GUID list as constructed by one 
embodiment of the present invention for the second exem- 
plary device network configuration of FIG. 10B. 

FIG. 12A illustrates a general GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
10A and FIG. 10B. 

FIG. 12B illustrates an "added" GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
10A and FIG. 10B. 

FIG. 12C illustrates a "removed" GUID update status list 
constructed by a second embodiment of the present inven- 
tion in response to the device network configurations of FIG. 
10A and FIG. 10B. 

FIG. 13 is a flow diagram illustrating steps performed by 
the present invention for constructing a GUID list in 
response to a local bus reset. 

FIG. 14 is a flow diagram illustrating steps performed by 
the present invention for constructing and communicating 
the GUID update status lists in response to a local bus reset. 

FIG. 15 A is a flow diagram illustrating the use of the 
GUID list in accordance with the present invention for 
sending a message to a device. 

FIG. 15B illustrates the use of the GUID list to provide an 
index in accordance with the present invention for accessing 
the speed map to determine communication speed informa- 
tion. 
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FIG. 15C illustrates the use of the GUID list to provide an initiative (HAVI) architecture. Aspects of the HAVI archi- 

index in accordance with the present invention for accessing tecture network (e.g., "HAVI architecture") are discussed to 

the topology map to determine topology information. provide a general framework in which embodiments of the 

FIG. 15D illustrates the use of the GUID list to provide an P resenl invention operate, 

index in accordance with the present invention for accessing 5 fe an architecture for inter-operating consumer 

the speed map to determine communication speed informa- electronics equipment devices adapted for the home net- 

tion where the application references the speed map. wo ' k \ ™ c interoperability aspects define an architectural 

>-rr n . ^ .„ " iL « - Trr> f. . , model that allows devices of any vendor to interwork within 

FIG. 15E illustrates the use of the GUID list to provide an the home A feature of the mNl ^tectoxt is the combi- 

indexm accordance with the present invention for accessing nation of a base ^ of generic device conilo]s ( a dev i ce 

the topology map to determine topology information where control software module) with a method to extend the base 

the application references the topology map. contro] pro tocol as new features and devices are deployed. 

DETAILED DESCRIPTION OF THE ^ nc architecture supports a wide range of devices 

INVENTION including intelligent receiver/decoders (IRDs), digital video 

15 tape records (DVTRs), video cassette recorders (VCRs), 
In the following detailed description of the present personal computers (PCs), digital video disk players 
invention, a method and system for providing efficient (DVDs), etc., communicating via a common messaging 
device identification using a GUID list within a consumer system. FIG. 1A illustrates the physical port-to-port con- 
electronics based audio/video network, numerous specific necting configuration 10a of an exemplary HAVI network, 
details are set forth in order to provide a thorough under- 2Q Several consumer electronics devices ("devices") 12-24 are 
standing of the present invention. However, it will be shown connected together with bus segments 30^-30/ which 
recognized by one skilled in the art that the present invention couple ("plug into") to ports on the respective devices. In 
may be practiced without these specific details or with one embodiment of the HAVI architecture, the IEEE 1394 
equivalents thereof. In other instances, well known methods, serial communication bus standard is used as a local bus 
procedures, components, and circuits have not been 25 platform to provide the common messaging system. The 
described in detail as not to unnecessarily obscure aspects of IEEE 1394 serial communication bus carries both 
the present invention. commands, status information and well as digital audio and 

digital video signals between devices. 

FIG. IB illustrates a logical bus configuration 10b of the 
Some portions of the detailed descriptions which follow 30 HAVI network of FIG. 1A. As shown in FIG. IB, all of the 
are presented in terms of procedures, steps, logic blocks, devices 12-24 of the HAVI network can be viewed as 
processing, and other symbolic representations of operations logically coupled to a common IEEE 1394 serial commu- 
on data bits within a computer memory (see FIG. 2). These nication bus 30. Within this bus configuration 106, peer-to - 
descriptions and representations are the means used by those peer device communication is supported. For example, as 
skilled in the data processing arts to most effectively convey 35 shown in FIG. 1C, any device (having appropriate 
the substance of their work to others skilled in the art. A capabilities), e.g., device 12, can send or receive commu- 
procedure, computer executed step, logic block, process, nication packets from any other device in the HAVI network, 
etc., is here, and generally, conceived to be a self-consistent In the example of FIG. 1C, the set-top -box (e.g., an IRD) can 
sequence of steps or instructions leading to a desired result. receive messages from or generate messages to any of the 
The steps are those requiring physical manipulations of 40 other devices 14-24 of the exemplary HAVI network, 
physical quantities. Usually, though not necessarily, these The interoperability model in the HAVI architecture pro- 
quantities take the form of electrical or magnetic signals v ides for the following: 1) support for existing devices; 2) a 
capable of being stored, transferred, combined, compared, default control model; 2) a means to extend the default 
and otherwise manipulated in a computer system. It has control model when new devices or functionality is brought 
proven convenient at times, principally for reasons of com- 45 to market; and 4) a common means for device representation 
mon usage, to refer to these signals as bits, values, elements, ( e .g., graphics user interfaces). To achieve the above, the 
symbols, characters, terms, numbers, or the like, HAVI architecture defines three types of nodes in the home 
It should be borne in mind, however, that all of these and network. A base AV (BAV) node is defined for devices that 
similar terms are to be associated with the appropriate already exist in the market (e.g., VCR 22 of FIG. 1A). An 
physical quantities and are merely convenient labels applied 50 intermediate AV (1AV) node is defined for simple devices 
to these quantities. Unless specifically stated otherwise as such as camcorders or DVTRs (e.g., camera 14). A full AV 
apparent from the following discussions, it is appreciated (FAV) node is defined for devices of more resources, such as 
that throughout the present invention, discussions utilizing IRDs or smart televisions (e.g., set-top-box 12). An FAV 
terms such as "processing" or "computing" or "translating" node (or device) typically contains enough hardware to host 
or "calculating" or "determining" or "displaying" or "rec- 55 control modules and to support application programs locally, 
ognizing" or the like, refer to the action and processes of a The IAV devices and FAV devices communicate by sending 
computer system, or similar electronic computing device, messages over the home network using a generic message 
that manipulates and transforms data represented as physical passing system described more fully below. When new 
(electronic) quantities within the computer system's regis- devices join the home network, they are recognized and 
ters and memories into other data similarly represented as go added to a global name database (registry). The registry 
physical quantities within the computer system memories or holds information about their characteristics and provides a 
registers or other such information storage, transmission or reference to a handler (e.g., communication point) for that 
display devices. device. Other devices and services are able to query the 

„ , „ „ „ „ registry to locate a device and then, using the handler, can 

HAVI ARCHITECTURE GENERALLY fi5 m * rac * with the device 

Embodiments of the present invention are operable within When a device is initially added to the home network, the 

a consumer electronics network of the home audio/visual system queries the device to ascertain its characteristics and 
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capabilities. Once a device's characteristics are known, the 
architecture provides two methods of controlling it. The first 
method, level one interoperability, uses a predefined mes- 
sage set based on IEEE 1394 AV/C-CTS. All IAV and FAV 
nodes can use this command set to access and control other 
devices, however, BAV nodes, because they are deployed 
before the architecture was defined, are controlled using 
legacy protocols. The level one interoperability provides a 
default level of control. The FAV nodes act as control nodes 
and create a local representation of the IAV node, known as 
a device control module (DCM), that provides an API used 
to send control commands to the device. 

Level two interoperability within the HAVI architecture 
goes farther and supports future added functionality and new 
devices. To achieve this, a particular device can carry within 
its ROM an override DCM that is uploaded from the IAV 
device, to the FAV device, and replaces the default DCM for 
the particular device. This override DCM not only contains 
the basic level one command set for the particular device but 
also includes vendor specific commands to control advanced 
features of the device. This model allows the device to 
inform another object about its particular functionality. 
Since the override DCM may be loaded onto any vendor's 
FAV, the format of the DCM is architecture- neutral. 

To allow one device to discover the capabilities of another 
device and to determine which command set to use with that 
device, a standard device description structure is provided 
called the self describing data (SDD) structure. The SDD 
data structure is extensible. It can be a small number of bytes 
describing the device type, e.g., TV, or VTR, etc. 
Alternatively, the SDD data structure can be a more complex 
structure also defining the override DCM and a graphical 
representation of the device. The graphical representation 
within the SDD data structure allows an FAV node to present 
a pictorial representation of the devices in the home network 
to users. 

By defining the graphical representation in a sufficiently 
generic manner, a device's SDD graphical data can be used 
in any vendor's product to display (e.g., on a television or 
monitor within the network) a user interface for that device. 
This provides an enhanced level of vendor interoperability 
and also allows a vendor to differentiate a product while 
maintaining within the general look and feel of the display 
device. The SDD also enables a control device (the FAV 
node) to present a general control user interface for all 
devices in the home network, irrespective of the differences 
in type and vendor. Self describing data (SDD) is described 
in copending provisional application serial number 60/054, 
327, entitled "A Method and Apparatus for Including Self- 
Describing Information within Devices," filed Jul. 31, 1997 
and assigned to the assignee of the present invention. The 
above referenced provisional patent application is hereby 
incorporated by reference. 

Legacy devices are devices that were built before the 
HAVI architecture or devices that select not to use the HAVI 
architecture. The HAVI architecture supports Legacy 
devices by providing Legacy DCMs to provide protocol 
conversions for Legacy devices. These Legacy DCMs can 
contain sufficient knowledge to allow them to support an 
existing 1 or 2 way control protocol and provide a specific 
control interface to the devices that conform to the HAVI 
architecture. A legacy DCM acts as a bridge between the 
Legacy and HAVI devices. This feature allows the HAVI 
architecture also to interact with any future device control 
protocols such as, for example, protocols being used for 
home energy management or security, etc. 

SET-TOP-BOX 12 OF FIG. 2 

Any consumer electronics device can be provided with 
the appropriate hardware to act as an FAV and thereby 
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provide a platform for certain HAVI software (described 
below). For instance, the set-top-box 12 device of the 
exemplary HAVI network of FIG. 1A contains special 
hardware components that provide an operation platform for 

S software components of the HAVI architecture. Another 
example of an FAV is a digital television having the required 
hardware resources to support HAVI software. Certain 
aspects of the present invention, described below, are dis- 
cussed in terms of steps executed on a computer system 

10 (e.g., processes 400, 700, 800, 850, 900a, 950a, 9006 and 
9506). Although a variety of different computer systems can 
be used with the present invention, an exemplary general 
purpose computer system is shown in the set- top-box FAV of 
FIG. 2. 

15 Set-top-box 12 of FIG. 2, in addition to having a video/ 
audio receiver (decoder) unit 106 and MPEG unit 107 also 
includes an internal address/data bus 100 for communicating 
information, one or more central processors 101 coupled 
with the bus 100 for processing information and 

20 instructions, a volatile memory 102 (e.g., random access 
, memory RAM) coupled with the bus 100 for storing infor- 
mation and instructions for the central processor 101 and a 
non-volatile memory 103 (e.g., read only memory ROM) 
coupled with the bus 100 for storing static information and 

25 instructions for the processor 101. Set-top -box 12 can also 
optionally include a data storage device 104 ("disk 
subsystem") such as a magnetic or optical disk and disk 
drive coupled with the bus 100 for storing information and 
instructions. Also included in the set-top -box 12 is a bus 

30 interface unit 108 for interfacing with the local bus 30 (e.g., 
an IEEE 1394 serial bus). Set-top-box 12 can operate under 
a variety of different operating systems (e.g., Windows 
operating system, DOS operating system, Macintosh O/S), 
but in one embodiment the Aperios operating system is used. 

35 HAVI SOFTWARE ARCHITECTURE 

In one embodiment, the software of the HAVI architecture 
can be broken into three APIs (AVOS, interoperability and 
application). The AVOS API is a low level system API that 

40 abstracts the common operating system services, e.g., 
threads, communications, and memory. Interoperability 
APIs are abstractions of common device control models and 
provide a basic representation model and a means to extend 
the control model with vendor specific commands. The 

45 application API is a high level API for applications including 
interactive TV applications, and in one embodiment is based 
on the DAVIC API set including the Motion Hypermedia 
Expert Group (MHEG) interactive application engine. 
FIG. 3 illustrates the software architecture 200 used in the 

so HAVI architecture in more detail. The architecture 200 
contains several generic components to provide abstractions 
of common facilities in the home network. Acommunication 
media manager 250 is provided and this component 
abstracts from the underlying transport network. In the case 

ss of the IEEE 1394, the communication media manager 250 
maintains and generates information regarding the speed 
maps 515 (FIG. 8) and topology maps 520 which are used 
by embodiments of the present invention. A DCM Manager 
270 is also provided that is responsible for identifying and 

60 creating generic DCMs 230 for level one interoperability. 
The DCM Manager 270 also hosts override DCMs uploaded 
from devices or other sites. A Graphics Management unit 
220 is provided which supplies generic graphics APIs that 
applications and DCMs can use to present user interface 

65 information. 

A Stream Manager 335 of FIG. 3 is used to determine the 
most effective route for AV streams within the home net- 
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work. A data format manager is included within the Stream 
Manager 335 and is responsible for providing conversion of 
AV streams to and from various formats as they flow 
between devices in the home network. These operations are 
described below with reference to FIG. 7A and FIG. 7B. A 
Messaging Manager 212 supports a generic messaging 
mechanism that allows devices to locate and interact with 
other devices in the home network. A communications 
media manager (CMM) 250 is a media dependent entity in 
the HAVI software architecture 200. The CMM 250 pro- 
vides abstract services to other HAVI components or appli- 
cation programs in the HAVI network. It also provides 
media specific transport mechanisms for actual data com- 
munication among various devices in the home network. 
The CMM 250 is responsible for compiling new GUID 
status updates upon a local bus reset. It is appreciated that 
each physical communication media contains its own CMM 
to serve the above purposes. As one example, the CMM 250 
for the IEEE 1394 serial bus is described herein further 
below. 

The Event Manager 214, the Registry 216, the Stream 
Manager 335 and the Initialization Manager 210 of FIG. 3 
are described separately further below. 

FIG. 4 illustrates a data flow diagram 305a with the HAVI 
software architecture 200 including an interface with the 
local bus HAL layer 330 for local bus 30. In diagram 305a, 
the top layer is an application program layer ("application 
layer") 220 which can communicate with a function control 
module (FCM) layer 314 having AVIC command. The 
application layer 220 resides within a FAV and can also 
communicate with device control modules (DCMs) 230 and 
with the Registry 216. The application layer 220 commu- 
nicates with a Stream Manager 335, The DCMs 230 are 
controlled by the DCM manager 270 which can communi- 
cate with the Event Manager 214. The Event Manager 214 
communicates with the CMM 250. The Stream Manager 335 
allows communication between the application layer and the 
CMM 250. The AV Messenger unit 212 also communicates 
with the CMM 250. The CMM 250 provides an interface 
with the local bus interface 330 via a link driver unit 320. 
The link driver unit 320 is responsible for compiling new 
GUID lists upon a local bus reset. Higher level applications 
are located with block 310 and lower level applications 
within block 312. A subset of this communication diagram 
305a is illustrated in FIG. 8. 

FIG. 5A is a diagram 340a that illustrates communication 
channels that are available for communicating to the CMM 
250. The application layer 220 communicates with the 
CMM 250 to obtain bus generation information, to obtain 
the GUID list, to obtain the speed map 515 and to obtain the 
topology map 520. The following APIs are used to perform 
these functions: getGUIDList( ); getBusGeneration( ); 
getSpeedMap( ); and getTopologyMap( ). The ilink trans- 
portation adaptation module, TAM, 2126 communicates 
with the CMM 250 for asynchronous requests and asyn- 
chronous responses. The digital I/F controller 335a commu- 
nicates with the CMM 250 for asynchronous requests, 
asynchronous responses, channel allocations, channel 
deallocations, bandwidth allocations and bandwidth deallo- 
cations. The Stream Manager 335 utilizes GUID informa- 
tion to establish point to point communications via the 
digital I/F controller 335a. The digital I/F controller 335a 
communicates with the CMM 250 using the following APIs: 
allocateChannel( ); deallocated] annel( ); 
allocateBandwidth( ); and deallocateBandwidth( ). The iso- 
chronous data transceiver 230 is a DCM and communicates 
with the CMM 250 using the following APIs: isoOpen( ); 
isoClose( ); isoAttach( ); isoDetach( ); and isoControl( ). 
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FIG. 5B is a diagram 340b that illustrates communication 
channels that are available for communicating from the 
CMM 250 to other objects. The CMM 250 communicates 
bus reset indications to the Event Manager 214. The CMM 

5 250 also communicates status information regarding the set 
of current devices on the local bus 30 including information 
as to which devices are added and which devices have been 
removed from the local bus 30 since the last GUID list was 
constructed. The CMM 250 also communicates bus reset 

10 information to the ilink TAM 2126 as well as GUID 
information, asynchronous receive, and isochronous 
receive. This same information is also communicated from 
the CMM 250 to the isochronous data transceiver module 
230. Information regarding which devices are coupled to the 

15 local bus 30 is also communicated from the CMM 250 to the 
digital I/F controller 335a. 

FIG. 6 illustrates an exemplary interface 360 between the 
CMM 250 and the local bus 30 for IEEE 1394 interfacing. 
A 1394 Bus Manager 370 is also shown. The CMM 250 

20 contains a copy of the speed map 515 and the topology map 
520 (described further below) and and IEEE 1394 Bus 
Manager 370 contains control/status registers (CSRs). The 
isochronous resource manager 372 contains information 
regarding the bus master identification and the available 

25 channels and bandwidth for communication via isochronous 
registers (CSRs). The node controller 374 contains a con- 
figuration ROM as well as node control registers (CSRs). 
Units 250, 372 and 374 constitute the serial bus management 
unit 370. Unit 370 communicates with 1394 HAL interface 

30 (I/F) layer 330. The transaction block 378 processes read/ 
write/lock transactions, tracks pending transactions and con- 
trols retry protocol operations with a busy/timeout register. 
Data transmission takes place within the link layer 380 and 
the I/F (CFR) unit 385. 

35 

DCM 230 AND DCM MANAGER 270 

A description of the DCM 230 and the DCM manager 270 
of FIG. 3, as well as other aspects of the HAVI software 

4Q architecture 200 are described in copending U.S. patent 
application Ser. No. 09/003,119, entitled "A Home Audio/ 
Video Network with Two Level Device Control", by R. Lea 
and A. Ludtke, filed concurrently herewith, attorney docket 
No. SONY-50L2278, assigned to the assignee of the present 

45 invention and hereby incorporated herein by reference. 

THE COMMUNICATIONS MEDIA MANAGER 
250 

The CMM 250 (e.g., for the IEEE 1394 bus) of FIG. 4 

50 provides two levels of APIs. One is the high-level API that 
interacts with other HAVI components to offer abstract 
services such as topology map 520 and speed map 515 as 
well as generating HAVI related events. The other level of 
APIs is the low-level API that provides a basic transport 

55 mechanism for both asynchronous and isochronous data 
transfers. Normally, high-level APIs are available to any 
HAVI entity or applications residing locally on this same 
node, while the low-level APIs presents the primary inter- 
face to the IEEE 1394 bus 30 so that specific protocols can 

60 be built on top of the CMM 250. To access high-level APIs, 
the HAVI message system (e.g., AvMessenger 212) is used, 
whereas access to low-level APIs can be accomplished 
through direct calls to the CMM 250. 
The messaging used to access high-level APIs through 

65 HAVI message system is done using a format having a 
multi-byte selector followed by function dependent param- 
eters. The function selector determines which service to use 
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from the CMM 250, and the parameters section provides all clients who are 1394-aware, and need such capabilities, can 

required parameters for the specified function. To invoke go through the 1394 CMM 250. 

low-level APIs, only the parameters section is necessary. One of the advanced features the 1394 bus provides to the 

The IEEE local bus 30 is a dynamically configurable HAVI architecture is its support for dynamic device actions 

network. After each bus reset, a device can have a complete 5 suc h as hot plugging (device insertion or power up) and 

different physical identifier (phy_id) than it had before the unplugging (device removal or power down). To fully 

bus reset. If a HAVI component or an application has been support this to the user level, high level software clients need 

communicating with a device in the HAVI network it to be aware of these environment changes and the present 

generally desires to continue the communication after a bus invention provides this information. The CMM 250 works 

reset even though the device may have a different physical *° with the Event Manager 214 to detect and announce these 

identifier. To identify a device uniquely regardless of fre- dynamic bus changes using device status tables (FIG, 12 A, 

quent bus resets, the present invention provides the Global FIG - 12B, FIG. 12 C). Since any topology change within 

Unique ID (GUID) which is used by the CMM 250 and other 1394 bus will cause a bus reset to occur, the CMM 250 is 

HAVI entities. A GUID is a multi-bit number (e.g., 64-bits informed of these changes and notifies the Event Manager 

in one implementation) that is composed of 24 bits of 15 214 of these changes along with the information about 

node -vendor identification and 40 bits of chip (series) iden- devices that have disappeared as well as those that have 

tification. While a device's physical identifier may change become available. The Event Manager 214 then distributes 

constantly, its GUID is permanent within the HAVI archi- the related event to all interested HAVI entities or applica- 

tecture. The CMM 250 of the present invention makes tions that previously established the proper call back han- 

device GUID information available for its clients using a 20 

GUID list discussed further below. There are two basic types of events that are generated 

The CMM 250 abstracts the underlying device intercon- hom the CMM 250 to su PP ort dvnamic updating of avail- 

nection mechanism, providing a common set of API's to able devices in thc nctwork * 0ne * NEW_DEVICE which 

describe the capabilities of the bus architecture. In one ""toates a new device, and the other is GONE_DEVICE, 

embodiment, the CMM concept is driven by the IEEE 1394 25 ""Heating a device has been removed. To increase efficiency, 

bus model, but is sufficiently abstract to provide a general the CMM 250 g enerates device statu * tables with this 

service for interconnection management. The CMM 250 information. Whenever a device is added or removed from 

provides APIs for 4 four basic concepts. (1) Channel: a the network, a bus reset is generated and CMM 250 finds and 

channel is a logical data connection that a bus can support. m a **** J^Jf of new/gone devices to the Event 

For technology such as IEEE 1394, this maps directly to 30 Mana S er 214 * ^ Event Manager 214 has requested such 

hardware support for multiple channels. For technology that service * Since NEW_DEVICE or GONE_DEVICE also 

only supports a single data connection, then this degenerates indicates the occurrence of a bus reset, the Event Manager 

to a single channel. (2) Bridge: a bridge is a connection 214 ma y also creale a BUS_RESET event based on the 

between two bus technologies and allows channels to span abovc information. It should be noted that all these events 

different bus technologies. (3) Node: a node is a physical 35 are g enerall y " loca V which means that the Event Manager 

endpoint for a channel and corresponds to a unit or summit 214 docs not g enerall y sendybroadcast such events to any 

in the HAV architecture. (4) Bandwidth: this is a metric of other nodes * 

how much data can be carried on a bus at any one time. ^ CMM 250 also P rovides topology, speed maps, and 

Bandwidth can be assigned to channels to support the otner environment descriptions to its clients. The topology 

required data rates for whatever data the channel is deliv- 40 ma P 520 <? lG ; 9A ) de P lcts me connectivity among physical 

er j n g devices. Within the present invention, it can be used to build 

u * i u * u. j * _* *u a human interface that helps the user understand how 

ror those bus protocols which do not support these j. , j j i ^ • * * . 

concepts, the results of API calls to their CMMs have limited £ VlCeS ™ ^f^o^r^ f 

results. For example, if a particular bus technology does not A< ™ e ,. s P eed m *? 515 9B ' FI °-»? P t0 ^ es '^f^™ 

t i *\ ' i1tn , . t f *u % 45 on the possible maximum speed that can be used for data 

support multiple simultaneous data transfer actions, then it . . . . . . ^ , . . . , ^ 

™f* i a u i» ,i! u •* transmission between any two devices in the network. Speed 

most likely reports only a single channel, even though it . c 4 . ' , A 4 , .... , r 

j AOP - ~,ii„ ™ ,♦ „u„* i„ tt,^ nut** -yma raa P s provide mformation about the connectivity and per- 

does not really support channels. The CMM 250 maps e c t . f(L TTA1 , , . TA J , K. A 

t™™*;™ ^*u. „L i a~i formance of sections of the HAV network. It can be used to 

transactions to the channel model. , 4l _ . , , 

. , , analyze the current connection scheme and give the user 

iil^^ 1S 0I ! e A^^!^i?i!!J\ P nvsic al interface (e.g. 50 hel M sllggestions for improving the performance of 

1394 Control Al, TCP/IP) on a FAV node. Because there de 4 es by Rearranging the connections. If attributes such as 

can be more than one kind of CMM 250, and because there ^ topology map 520 cannot be automatically generated, 

can be many of them in existence, each CMM 250 has a ^ a dialog ^ ^ ^ may be required a 

module_type attribute attached to its entry in the Service topo io gy request is made to a CMM for a protocol that does 

Registry 216 database. The definition of this attribute can be 55 not support automatic topolo g y detection, the request can 

as to Hows. trigger such a dialog. After interacting with the user to 

module_type=busManager determine how its devices are connected, the CMM returns 

module_data={1394, Control Al, TCP/IP, etc.} These the requested information, 

bus types will have numeric identifiers defined for Topology map 520 and speed map 515 may change 

them, 60 constantly because their organization (e.g., data order) is 

Each CMM 250 contains the general set of API's for bus based on the physical identifiers of the devices on the 

management, as well as protocol-specific API's. If a par- network and these values can become reassigned due to the 

ticular bus technology supports features that are above and allowed dynamic insertion or removal of devices. To iden- 

beyond the general model, then it can subclass the CMM tify the right "version" for these maps, a bus generation 

base class and add the new functionality. For example, the 65 number may be used. Newer bus generation values signify 

1394 CMM 250 allows access to the 1394-specific bus the change ofbusconfiguration.lt may also be used to check 

attributes such as the isochronous resource manager. Those if a pending operation is "stale". Since transactions between 
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devices require the existence of those devices, it is possible 
that a pending transaction has not yet completed and one or 
more devices involved have gone away. When this happens, 
a new bus generation number will be generated and the 
related process can check against this new generation num- 5 
ber to make proper clean up for the stale transaction. 

Bus generation number, topology map 520, and speed 
map 515 remain unchanged between bus resets. To improve 
efficiency, the CMM 250 may optionally cache them inter- 
nally and keep them updated only when bus reset occurs. 10 

Another feature of the IEEE 1394 bus 30 is its capability 
to send timingcritical stream through its isochronous chan- 
nels. To send data in isochronous mode, channel number and 
proper bandwidth need to be allocated from the bus. The 
CMM 250 provides such services to allocate/deallocate 15 
channel numbers and bandwidth for its clients. It is also 
responsible to restore these resources for its clients right 
after each bus reset so that any existing isochronous data 
transaction will not be disrupted because of the unavailabil- 
ity of these resources. 20 

The CMM 250 also provides a transport mechanism to 
actually transfer the data, which is part of low-level services. 
There are two types of data transactions with IEEE 1394 bus 
30. One is asynchronous, the other isochronous. Typical 
asynchronous transfer includes quadlet/block write, quadlet/ 25 
block read, and lock operations. Typical isochronous data 
transfer normally involves allocating channel/bandwidth, 
opening isochronous data port, attaching data buffer(s), and 
activating data transfer. These services provide a fundamen- 
tal transport mechanism for a 1394 based HAVI system 30 
being functional. 

The following APIs are provided by IEEE 1394 specific 
CMM 250 within the present invention: 

1) CMM::enrollComeNGo( ) 

Status: enrollComeNGo(ObjectID oid, (void *) (*) 35 
callback^ andler) 

This command is used by the Event Manager 214 to get a list 
of new and removed devices when bus reset occurs. The 
Event Manager 214 enrolls such request to the CMM 250 to 
get the service. The parameter oid is the caller's object 40 
identifier and callback_handler is the callback function 
provided by the caller. The caller (typically Event Manager 
214) enrolls its OID and a callback handler to the CMM 250 
so that when bus reset occurs, the CMM 250 invokes the 
callback function with a list of devices (device status table) 45 
that are either new or gone. 

2) CMM::getGUIDList( ) 

Status: CMM250::getGuIDList(GUID *guid) 

This command gets the GUID for all active devices in the 

network. The parameter guid is a pointer to a the GUID list. 50 

3) CMM::getBusGeneration( ) 

Status: CMM::getBusGeneration(uint32 *bus_en_ 
number) 

This command gets the current local bus generation number 
from the network. 55 
The parameter bus_en_number is the current bus genera- 
tion number. 

4) CMM::getSpeedMap( ) 

Status: CMM::getspeedMap(uint32 bus_en_number 
u_char *spd_map) 60 

This command gets the speed map 515 which is associ- 
ated with the bus generation number specified. The param- 
eter bus_en_number is the current bus generation number, 
spd_map is a pointer to the speed map 515 

5) CMM::getTopologyMap( ) 65 
Status: CMM::getTopologyMap(uint32 bus_en_jiumber, 
uint32 * top_map) 



This command gets the topology map 520 that is associated 
with the bus generation number specified. The parameter 
bus_en__number is the current bus generation number and 
top_map is a pointer to an array of integer numbers, each 
representing a selLID packet from a 1394 node. 

6) CMM::allocatechannel( ) 

Status: CMM:: allocate Channel(uint32 chan_no) 
This command allocates a channel specified by chan_jio. If 
chan_no is all ones (Ox FFFFfTff), any channel available 
will be allocated and returned. The parameter chan_jio is a 
channel number to be allocated. 

7) CMM::deallocatechannel( ) 

Status: CMM::deallocateChannel(uint32 chan__no) 
This command deallocates a channel specified by chan_no. 
The parameter chan no is the channel number to be deal- 
located. 

8) CMM::allocateBandwidth( ) 

Status: CMM:: allocateBandwidth(uint32 bandwidth) 
This command allocates the bandwidth specified by band- 
width. The parameter bandwidth is the bandwidth to be 
allocated. 

9) CMM::deallocateBandwidth( ) 

Status: CMM::deallocateBandwidth(uint32 bandwidth) 
This command deallocates the bandwidth specified by band- 
width. The parameter bandwidth is the bandwidth to be 
deallocated. 

10) CMM::asyncWrite() 

Status: CMM::asyncWrite(GUID guid, u_int64 remote_ 
offset, u_char *data, uint32 data size, uint32 pk_format) 
This command sends an asynchronous write request to the 
remote device, which is identified by guid. The parameter 
guid is the target device's GUID, remote_offset is the target 
device's memory offset, data is a pointer to data to be sent, 
data_size is the size of data (in byte) to be sent and 
pk_format is the format to use, either quadlet or block for 
data transfer. 

11) CMM::asyncRead() 

Status: CMM::asyncRead(GUID guid, u_int64 remote„ 
oflset, u_char *data, uint32 data_size, uint32pk_format) 
This command sends a asynchronous read request to the 
remote device, and returns the data read back. The parameter 
guid is the target device's GUID, remote_oflset is the target 
device's memory offset, data is the pointer to data to be 
received, data_size is the size of data (in byte) to readback 
from remote site, and pk _J:ormat is the format to use, either 
quadlet or block for data transfer. 

12) CMM::asyncLock() 

Status: CMM::asynclock(GUID guid, u^int64 remote_ 

offset, u char *old_data u_char *new data, uint32 data__ 

size uint32 exLcode) 

This command makes a lock operation on the specified 
address in the remote device. The parameter old_data is 
used for compare and swap operation. The parameter guid is 
the target device's GUID, remote_offset is the target 
device's memory offset, old_data is the pointer to old data, 
new_data is the pointer to the new data, data__size is the 
size of data (in byte) to be sent, and ext_code is the 
extended code to be used for the lock operation 

13) CMM::isoOpen( ) 

Status: CMM::isoOpen(uint32 direction, uint32 bus_speed, 
uint32 bandwidth, uint32 * port -no) 
This command opens an isochronous port for either sending 
or receiving operation. The actual port opened is returned in 
port__no. The parameter direction is the sending or receiving 
operation, bus_speed is the requested bus speed, bandwidth 
is the maximum bandwidth to be used, and porLno is the 
port number successfully opened. 
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14) CMM::isoQose( ) have bus-specific knowledge. The topology map 520 can be 
Status: CMM: :isoQose(uint32 port_no) generated automatically for those control protocols which 
This command closes the port specificed. The parameter support it, or can be generated with user interaction and 
port_no is the port number to be closed Close the port stored for later use for those protocols that do not support 
specified. s automatic generation. Because topologies can be quite 

15) CMM::isoAttach( ) diverse, the CMM 250 provides a topology iterator function 
Status: CMM::iosAttach(uint32 porLno, u_char * buffer) similar to that of the Service Registry 216. This function 
This command attaches a user buffer to the specified port. allows clients to visit each node in a connection-specific 
The parameter porLno is the port number to be used and manner, with a simple API to move forward or backward 
buffer is the data buffer. 10 through the net. The client can determine simply that this 

16) CMM::isoDetach( ) device is connected to that one, which is connected to that 
Status: CMM::iosDetach(uint32 port_jao, u_char *buffer) one, etc. For clients who simply need to know about all 
This command detaches a user buffer from the specificed devices in a topology, with no concern for connection 
port. The parameter port_no is the port number to be used patterns, the GUID list is provided. Other API's allow the 
and buffer is the data buffer. 15 query to determine if a given modulelD (the identification of 

17) CMM::isoControl( ) a DCM which represents a physical device) is represented in 
Status: CMM::isoControl(uint32 chan, uint32 trigger) the topology, etc. 

This command controls the actual data transfer. It starts The CMM 250 also provides logical connection informa- 

immediately or on some synchronization bit. The parameter tion. This is a connection model that specifies data flow 

chan is the channel to be used for the transfer and trigger is 20 sources and sinks. The API allows inquiries such as "given 

the method to use to start the trafiEc, DCM module ID X, tell caller all of the DCMs that are 

In addition to the basic four abstractions discussed above listening to it/' Other variations on this inquiry model 

(Node, Channel, Bridge and Bandwidth), the following include the ability to ask for all currently active streams of 

concepts describe the bus model. The topology map 520 is a particular data type (e.g. MPEG, SD), etc. 

a connected graph which mirrors the physical connections 25 

between nodes on the network. For IEEE 1394, the map is EVENT MANAGER 214 

generated automatically. For other protocols, manual assis- ^ Eycnt M f 214 of mQ 4 ^ desi d tQ t 

tance from the user may be required The overall system a one-to-many model of communication. It is built above the 

topology is an amalgamation of individual bus topologies. bask messaging s stem 212 . objects register interest in 

The generation number provides a way to measure whether 30 events which are then deHvered to their eyent call back ent 

a pending operation is stale. Since transactions between For inslance> objects i[lterested in device status informa tion 

devices depend on being able to access those devices it is r ^ ial call back handlere for this information ^ 

possible that a pending transaction has not yet completed the £vem Manager 2U QW can attacfa £vem fiUers tQ 

and one or more of the devices involved have gone away. the callback entries that ^ ^ to mter Qut eyents that 

When this happens, any modules that care about the bus 35 lhey are fl0t cm ^ y ^rcstzd in. For example an object 

generation react accordingly. may register for all events from display devices, but filter out 

The generation value is based on the ability to determine those ^ u devices u fc not usi 

that the bus configuration has changed. For protocols such as _ 4 , . 1L A 

IEEE 1394, the generation is critical because of hot plugging A , Even ^ are feasted by the messaging system 212 and 

support. For others, if hot plugging support can be 40 delivered to all objects that rmve registered an mterest in the 

simulated, then the generation number can be managed as ™ nt J° , ac c hleve * ls ' object fg^ster then- interest with 

weU. If no hot plugging support can be created, then the J«r local Event Manager 214. The messaging system 

generation number will always default to "1," meaning that delivers event f , to f known Even ' Mana i els 214 which are 

the bus has not changed since the host system was initial- th f res f on f 1 b,e for mat objects are 

ized. A bus can allow a certain maximum number of nodes 45 ?/ ormed *° ut ^nts. Filters can be attached to Event 

(devices) to be connected and individually addressable at Managers 214 to allow objects to filter out the events as they 

any given time. At any given time, the CMM 250 is amve. This gl ves an object the flexibihty to register mterest 

informed of how many devices are currently attached and ™ an even !> bu ' have °°° tr L ° 1 ove ] how each 15 ^ d " 

addressable (number of nodes) For 6xam P le a filt6r te to that cvent X 15 

As described more fully below, the CMM 250 provides 50 ^ of f^Jf rf U °f cn,s a ^ er event J- E ™ Dt Mana 8 er 

bus reset or change notification for buses that support 214 ^^j 15 , ^ET^?? ^ . * P Z 

dynamic connection. After a bus reset is detected, this UoDS and DCMs t0 bmld "Ph^ted event filtering chains, 

module assigns new "opaque" ID values to all devices that STREAM MANAGER 335 
have just appeared, determines what devices have gone 

away, invokes the DCM Manager 270 module to create new 55 The Stream Manager 335 of FIG. 4 provides an API for 
DCMs, and posts a bus__chaoge notification event to the configuring end-to-end isochronous ("streaming'*) connec- 
Event Manager 214, which notifies all registered clients tions. Connections may be point-to-point or utilize unbound 
about the reset. In accordance with the present invention, it sources or sinks. The responsibilities of the Stream Manager 
also provides enough information for the clients to deter- 335 include: configuration of connections; requesting allo- 
mine what devices have disappeared and about any newly 60 cation of network resources; maintenance of global connec- 
discovered devices. The CMM 250 works with the Event tion information; and support of high-level stream opera- 
Manager 214 to detect and announce dynamic bus changes tions such as plug type checking, splicing and bridging, 
that do not trigger system- wide interrupts or events, thus A Stream Manager 335 runs on each FAV node. The 
bringing some of the advantages of 1394 technology to other interface is based on the IEEE 1212 unit directory model and 
bus protocols. 65 the IEC 6 1883-FDIS plug model (HAVI refers to units and 
The CMM 250 provides clients with the physical topol- subunits as devices and functional components 
ogy map 520, in a manner that does not require clients to respectively). Point-to-point connections and broadcast con- 
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nections are supported. In IEEE 1394, a broadcast connec- and a connection from the channel to the input plug); it adds 
tion is one in which either the source or sink is not specified an output plug and an input plug to the stream (assuming 
when the connection is requested. Streams do not cross neither are already members). StartBroadcast creates a 
transport boundaries, but bridge devices can be used to feed "broadcastouf connection (e.g., a connection from an out- 
one stream into another. Streams originate and terminate at 5 P ut P^g to tne channel); it adds an output plug to the stream 
functional components (rather than devices). For IEEE 1394 (assuming it is not already a member). Tap creates a 
networks, the Stream Manager 335 is responsible for alio- "broadcast-in" connection (e.g., a connection from the chan- 
cating PCRs (plug control registers) and requesting bus Del to w ^ P lu S>; il adds an ^ P lu S to & c stream 
bandwidth. A standard naming scheme is used for stream (assuming it is not already a member). Disconnect, Stop- 
types, transport types and transmission formats. The stream 10 Broadcast and Untap drop the connections created by 
type and transport type naming schemes are specified by °? nne # StartBroadcast and Tap respectively. Ihey remove 
HAVI, transmission formats are the FMT/FDF values used plu <f < rf n ° ^ by oth f c — ons ^ the /™ m) , 
in IEC 1883 Common Isochronous Packets, . the °^ m f of connections as descried 

m IEC-1883, e.g., a plug may have many connections (both 

A stream type identifies a media representation, this can point-to-point and broadcast) to the channel used by the 

be a data format (for digital media) or signal format (for 15 stream Following the connection semantics of IEC-1883, 

analog media), e.g. CD audio, NTSC. A transport type the Stream Manager 335 decides when to remove a plug 

identifies a transport system, two examples are IEC 1883 from a stream by examining the plug's point-to-point con- 

(for connections running over 1394) and "internal" (for nection counter and a broadcast flag (which indicates 

connections internal to a device). A transmission format whether or not the plug participates in a broadcast 

identifies the data transmission protocol used to send a 20 connection). A plug is removed from a stream when the 

stream type over a transport type. For IEC 1883, the trans- point-to-point connection is 0 and the broadcast flag is false, 

mission format corresponds to the FMT and FDF fields in The underlying network resources used for a stream are 

the Common Isochronous Packet (CIP) header. allocated when the first plug is added to the stream and 

a ct,.^ n * 11£ _j u„ iUo „ ™ • ■ , _ released when the last plug is removed. In the case of a 

A stream as used by the Stream Manager 335 is based on , , • j * i • * i *i_ 

... . j . a j i £_ T ^ -y oo<i *i_ 25 channel connected to several output plugs, the manner in 

tfie isochronous data flow model from IEC 1883 with three 25 whjch ^ ^ ^ flow ^ d H elive P re |^ ^ t , 

differences. The first difference is that streams do not restnct dependent and the stream Manager 335 does not guarantee 

the number of sources and so can have multiple sources mat M input plugs wjll receive data in thc same onkr 

provided the transport supports this form of connectivity, for ^ ^ m Mlnag6r 335 maintains a map of all stream 

example^ UDP event stream being fed by many pro- conaections the home network ^ indudes 

cesses. The second difference is that an IEEE 1394 data flow ■ # i /,« j - \ j t 

4 _ . j . , , , j.. , internal connections (those within devices) and external 

starts at adevice outpu plug and ends at a device input plug, connections (those over t rt tems) ' ^ Stream 

whole a stream typically starts at a funcUonal component Manager 335 builds the Global Connection Map upon 

output plug, goes to a device output plug, then a device input mitializadoni ^ bus 

reset, and periodically while running 

plug, and ends at a functional component input plug. The /■ . . jj j j u 

£ i j rc .... . , r , 35 (m case new connections have been added or removed by 

final difference is that streams are typed, e.g., for each UA , n v .* \ 

*u • ■ . j , , \J b . ' . , A non-HAVI applications), 

stream there is an associated stream type identifying the data A AW , , , . A , . . 

, /r v An network can take on many topological 

The following summarizes the properties of streams: 1) a configurations, depending on how the user has made the 

stream is associated with a globally unique stream identifier; connections between devices. For example, an IEEE 1394 

2) a stream is carried over a single channel; 3) output 4Q bus aUows any topology except a loop. The Stream manager 

functional component plugs ( plugs ) and input plugs can 335 of FIG 3 works with the CMM 250 tQ ide services 

join a stream (this can also be stated as "connect to the to ^ ^ routing daU from to dcstination . ^ 

channel ); 4) a channel can be connected to zero or more can include many nodes ^ betweeil( Iq ^ event mat the 

output plugs and zero or more input plugs; 5) an input plug sourcc ^ destirjation involvc mmat data typcs , or arc 

can jom at most one stream; 6) an output plug can join many 45 separated by a « data type barrier - it ^ work ^ a data 

streams (for example a functional component output plug format manager and Sejvice Registry 216 t0 haodle aut0 . 

attached to several device output plugs); 7) a stream can be matic or request ed data translation services as well. Some 

created with no output plug, but no data will flow over the rcmting can be perforrned automatically, based on the capa- 

stream until an output plug has joined; and 8) the upper limit biMes prov i ded by the underlying bus architecture. For 

on the number of plugs that can be connected to a channel 5Q example , the topology of the IEEE a394 bus ^ be prec isely 

is transport type dependent. determined, and therefore automatic routing between 

A stream can be viewed as a set of plugs. The following directly-connected 1394 devices can be achieved. However, 

rules apply to connections within a device. Functional other connection mechanisms can require interaction with 

component input plugs can have only one connection (from the user, either to assist the user with making well-known 

a functional component output plug or a device input plug). 55 connections or to have the user indicate to the controlling 

Functional component output plugs can have many connec- software how devices are connected, 

tions (to functional component input plugs and/or device One of the most significant attributes of the IEEE 1394 

output plugs). Device output plugs can have only one technology is isochronous data flow. Additional services 

connection from a functional component output plug. provided by the Stream manager 335 for this kind of data 

Device input plugs can have many connections to functional 60 mc i u de buffer allocation and management. Buffer manage- 

component input plugs. ment includes the provision of a consistent notification 

There are three procedures for adding or removing plugs mechanism to let the client know' when data is available, so 

from this set: 1) point-to-point procedure (Connect, that it can be processed. While isochronous data is flowing 

Disconnect); 2) broadcast-out procedure (StartBroadcast, into a client, various memory buffers will be filled with that 

StopBroadcast); and 3) broadcast-in procedure (Tap, Untap). 65 data. As each buffer is filled, the client may want to know so 

Connect creates a point-to-point connection between two that it can handle the data acquisition process from that point 

plugs (e.g., a connection from an output plug to the channel forward. 
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In addition, buffer management can be simplified for 
clients by having the appropriate service modules partition 
memory in a manner that is optimized for the data being 
captured. For example, the client can allocate one large 
space of memory, then specify that it will be used for 
capturing a stream of video data. It is possible that the 
optimum configuration of this memory is to separate it into 
scan line- or frame -sized segments, so the client can receive 
one complete line or frame of video on each notification. 
Raw audio and MIDI data will likely have different optimum 
segment sizes, Such services require close cooperation 
between the Route and Data Format Managers, and various 
service modules. 

Refer to FIG. 7 A and FIG. 7B where an example process 
400 is shown for setting up a data flow. A client wants to 
establish a connection between two devices, so at step 410 
it calls to establish an external connection of one of the two 
DCMs that represent those devices. It passes the modulelD 
of the other device's DCM as a parameter. At step 415, the 
DCM that was called then calls the Stream Manager (SM) 
335 to assist with making the connection. It passes both the 
source and destination DCM module IDs as parameters. At 
step 420, the SM 335 analyzes the source and destination 
IDs, finds that they are in different nodes (this step may be 
carried out by some other entity before invoking the DFM). 
At step 425, the SM 335 asks the CMM 250 of the source 
node for the topology map 520 for its network. At step 430, 
the SM 335 analyzes the topology map 520 to find the 
destination node. 

At step 435 of FIG. 7 A, if the destination node is on the 
topology map 520, then no transport protocol translation is 
necessary and step 445 is entered directly. If the destination 
node is not on the map, then at step 475 (FIG. 7B) the SM 
335 asks the Registry 216 for the module with the 
destinationID, to look at the "transmission^protocol" 
attribute, or alternatively, it gets the bus manager ID for that 
module/node. At step 480, the SM 335 then finds a trans- 
mission protocol service module, and sets up the conversion 
process (see separate example for these details). At step 485, 
the above process is repeated if multiple transports need to 
be bridged. 

At step 445 of FIG. 7A, the SM 335 analyzes the 
connection paths to find the best route. If no deterministi- 
cally optimal path can be determined, then a best guess is 
accepted. This is done for the entire path from source to 
destination, including intermediate or cross-network bound- 
aries. All necessary connections are made (in the case of 
dynamic buses such as 1394). At step 450, the SM 335 
analyzes the input data formats for source and destination. 
At step 455, if the formats are the same, then no format 
conversion is necessary. At this point (465) the data flow 
route 400 is complete. 

If conversion is necessary, then at step 460, the SM 335 
asks the Registry 216 for the appropriate format converter 
based on input and output format and sets up the conversion 
process. Note that several converters can be chained together 
to achieve the final result from original source to desired 
destination formats. The data flow route 400 is then com- 
plete, 

SERVICE REGISTRY 216 

The Service Registry 216 of FIG. 4 provides a mechanism 
to locate devices and services that are available in the HAV 
network. Since all devices and services are represented by 
objects, the Service Registry 216 allows any object to 
advertise itself. Typically, resident on an FAV, the Service 
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Registry 16 contains information on local service objects, 
remote service objects and local and remote devices. The 
Service Registry 216 operates by providing an API that 
allows objects to register their unique identifier, a name, and 

s a set of attributes that define their characteristics including 
connection point information. Any object wishing to locate 
a particular service or device object can do so by querying 
the Service Registry 216 for the appropriate DCM. 
Attributes associated with an object may be static or 

10 dynamic, and can be subsequently changed if desired. 
Attribute querying is carried out by specifying a set of 
required attributes which then returns a list of objects that 
match the required attributes. Identifiers returned as a result 
of a query are not guaranteed to be valid. This can happen 

15 in one of two ways. First, if a device has posted its 
availability into the registry and then has gone off-line. If the 
query arrives between the time of going off-line and actually 
withdrawing the service from the registry, then the identifier 
will be stale. Second, if a query returns a set of identifiers, 

20 the results may be held within an object for an extended 
period of time. When they are finally used, it may be that the 
service has been withdrawn from the registry. 

The Service Registry 216 is a distributed service. Any 
object that registers with its local Service Registry will be 

25 accessible via any other instances of the Service Registry 
216 in the HAV network. Each Service Registry 216 works 
with others to ensure that entries are replicated or available 
when required. However, for both performance and resource 
reasons, it is often the case that an item registered in one 

30 registry will not be visible in another, although the system 
will try to ensure this. This implies that a simple query to a 
local Service Registry 216 may return the local registry's 
view of the global state. It will always be possible to cause 
a remote query to be carried out on behalf of the query to 

35 ensure that the global state of the system is queried explic- 
itly. 

Queries to the Service Registry 216 return object identi- 
fiers usable as end point for message communication. These 
4Q identifiers may refer to DCMs, services, or any other entity 
in the system accessible via the messaging system. The 
format of the queries allows both sophisticated queries that 
iterate over the global registry or simple queries that are 
confined to a local registry. 

45 MESSAGING 212 

The messaging system 212 of FIG. 3 is designed to 
provide a reliable high level messaging service that supports 
the transport of 4 different types of messages. (1) Com- 

50 mands: these flow between objects in the system and are 
used to access functionality. When the target object is a 
device then these messages are sent by a DCM and contain 
actual device control messages. (2) Events: events are used 
as a general purpose asynchronous communication mecha- 

55 nism that allows both devices and service modules to 
communicate information. Although the messaging system 
212 is used to carry these events they are under the control 
of the Event Manager 214 which uses a broadcast feature of 
the communications infrastructure to send events to those 

60 who are interested. (3) Errors: errors are similar to events 
except errors are delivered to the source of the command that 
caused the error and then broadcast. (4) Status: these mes- 
sages are designed to be used in response to a query. 
The message system 212 provides both a synchronous and 

65 an asynchronous send allowing services to operate in either 
mode. The messaging system 212 defines a minimum capa- 
bility to allow interoperability at the message level. This 
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includes the format of identifiers, the format of message 
identifiers and the format of messages. 

The following illustrates an exemplary implementation. 
Local identifiers are 56 bit and are guaranteed to be unique 
to a particular host. Network identifiers are 128 bits and 5 
consists of a 64 bit node identifier, an 8 bit node type and the 
56 bit local identifier. The generic format for remote mes- 
sages is a 4 octet type field followed by a parameter block. 
This is referred to as the message payload. The mechanism 
to support local messaging is implementation dependent and 10 
what is required is that local identifiers guarantee consistent 
delivery of the message payload. Remote messaging takes a 
message payload and encapsulates it in a network message. 
The network message format is header plus message pay- 
load. The network message header is 96 bits and consists of 15 
a reserved 6 bit field, a 2 bit packet type, a 56 bit local 
identifier and a 32 bit message identifier. Depending on the 
actual transport mechanism, this remote message packet will 
be encapsulated in a transport specific message, e.g. IP or 
IEEE 1394. 20 

INITIALIZATION MANAGER 210 

The Initialization Manager 210 of FIG. 3 is used to bring 
an IAV or FAV node up to initial status. In the case of an IAV 
node this manager 210 will initialize the messaging 212, 25 
event 214 and registry 216 service. For the FAV node it will 
also invoke initialization routines for the DCM manager 270 
and any pre-loaded services. 

APPLICATION INTERFACE 220 

30 

The Application Interface 220 of FIG. 4 is a proxy to the 
messaging system 212 and provides a means for applications 
to access services and devices in the AV architecture. The 
Application Interface 220 is not necessarily a component of 
the AV architecture, but rather a means of allowing an 35 
arbitrary application to work with the AV architecture. The 
mechanism used to provide the application object depends 
on the location of the application and the execution envi- 
ronment it uses. Applications can be downloaded from 
external services provided and made resident (e.g., 4Q 
instantiated) within an intelligent device (FAV) of a HAVI 
network. An Application so downloaded can query the 
Service Registry 216 to determine connection points for 
controlling devices of the HAVI network. 

There are 3 general cases. The first case is local applica- 45 
tion running native on the FAV node. These types of 
applications are designed to make use of the native OS and 
hardware features of the FAV node. They are created exter- 
nally to the AV architecture and use the application interface 
to gain access to the AV architecture services. The exact 50 
means to achieve this are system dependent, but a library 
linked into the application is a typical approach. 

The second case is local application running above the 
FAV interoperability language run-time. In this case, the AV 
architecture uses an architecture neutral run time to support 55 
level 2 interoperability. This run time can also be used to 
support arbitrary applications written to be hosted on the run 
time. Such applications are managed by the AV architecture 
and will typically access the AV services via a run time 
supplied calling mechanisms. $q 

The third case is remote application. These applications 
may be running on other devices in the home network such 
as home personal computers (PCs). These applications need 
access to the AV architecture and do so by using the basic 
message passing model of the system. This implies that 65 
these applications need a partial implementation of the 
messaging infrastructure resident on their host node. 
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GRAPHICS MANAGER 218 

The Graphics Manager 218 of FIG. 3 provides a high 
level API for the management of the user interface (UI) 
associated with devices. The role of the Graphics Manager 
218 is to support the User Interface model by providing a 
graphics API that is semantically rich. Low level graphics 
APIs are generally located close to graphic displays and are 
used by the high level graphics API to provide and support 
the UI. 

DEVICE IDENTIFICATION PROCESSES OF 
THE PRESENT INVENTION 

FIG. 8 illustrates a portion 305b of the HAVI communi- 
cation architecture and illustrates an application layer 220, a 
device control module 230 for a particular device 20, the 
CMM 250, the link driver layer 320, an electronic device 20 
coupled to the IEEE 1394 communication bus 30 and the 
speed map 515 and topology map 520 data structures. The 
location of the CMM 250 and the link driver layer 320 in the 
overall architecture of HAVI is shown in interface 305a of 
FIG. 4. 

As described above, the present invention allows high 
level software programs (e.g., the application layer 220) to 
reference devices using a persistent identification scheme. 
Namely, multi-bit persistent Global Unique Identifier num- 
bers (GUIDs) are assigned to each device and contain a 
vendor portion and a chip series portion. In one 
embodiment, a 64-bit number is used as the GUID. FIG. 8 
illustrates an exemplary communication path whereby the 
application layer 220 issues a command to cause device 20 
to perform some predefined action (e.g., to start "playing" 
some media). The initial command from the application 
layer 220 includes an abstract identifier (e.g., "VCR1") of 
the DCM 230 object and also the action to be done (e.g., 
"play"). 

The DCM 230 of FIG. 8 converts the abstract object name 
into a GUID that matches device 20 and issues another 
command including the GUID and the action, "play," to the 
CMM 250, The CMM 250 contains a GUID list 510 in 
accordance with the present invention. The GUID list 510 is 
a listing of GUIDs in order of their associated physical 
identifications (for each respective device). Therefore, the 
GUID list 510 of the present invention functions as an 
efficient physical identification to GUID translator and a' 
GUID to physical identification translator. The GUID list 
510 is updated by the link driver 320 each time a bus reset 
event is detected. 

The CMM 250, using the GUID list 510, converts the 
GUID received from the DCM 230 into the corresponding 
physical identifier for device 20. The CMM 250 then passes 
a message to the link driver layer 320 including the action 
command, "play/' and the physical identifier corresponding 
to device 20. The link driver layer 320 interfaces with the 
local bus 30 using the physical identifier thereby commu- 
nicating the action command, "play," to the device 20. The 
speed map 515 and topology map 520 are present for other 
aspects of the present invention described further below. 

FIG. 9 A, FIG. 9B and FIG. 9C illustrate exemplary speed 
map 515 and topology map 520 data structures. The entries 
of the speed map 515 and topology map 520 data structures 
are organized (e.g., ordered or indexed) based on the physi- 
cal identifier of the devices. The mechanisms for generating 
the speed map 515 and the topology map 520 data structures 
are well known within the IEEE 1394 standard. 

FIG. 9 A illustrates an exemplary topology map 520 data 
structure used by the present invention. This data structure 
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520 includes a respective entry (of entries 522a-522/i) for FIG. lOAand FIG. 10B have been reassigned due to a local 
each of the n devices coupled to the local bus 30. The first bus reset. The reassigned physical identifiers for the remain- 
field 524 of each entry corresponds to the device's physical ing devices are as follows: device 562 has physical identifier 
identifier as assigned by the local bus layer 330. As shown (0), device 564 has physical identifier (3), device 568 has 
in FIG. 9 A, the entries 522a-522n are ordered according to 5 physical identifier (4) and device 570 has physical identifier 
their physical identifier, e.g., physical_ID0, (2). Each of the GUID values is unique and persistent for all 
physical__IDl, . . . , physical_IDn. The following fields 526, devices. 

528, 530 for each entry specify port information for each FIG. 11B illustrates the resulting GUID list 5106 com- 

physical port of the device. The port information indicates piled by the present invention based on the exemplary HAVI 

the physical connection of that port to another port. Using network 5606 of FIG. 10B. The GUID list 5106 contains six 

this port information, one can determine the manner in entries, one for each device of the HAVI network 5606. As 

which the n devices of the local bus 30 are physically shown, the GUID values in the GUID list 5106 are ordered, 

coupled together in the HAVI network. Topology map 520 e.g., GUID(Y); GUID(U); GUID(X); GUID(Z); GUID(J) 

data structures of the format shown in FIG. 9 A are well and GUID(N), according to the corresponding physical 

known in the art and are re-generated upon each local bus identification values, 0, 1, 2, 3, 4 and 5, respectively. In one 

reset. 15 embodiment, the GUID list 5106 is compiled by the link 

FIG. 9B illustrates an exemplary one-dimensional speed drivcr 320 and storcd in computer readable memory, 
map data structure 515a used by the present invention. This FIG - 12 A illustrates a GUID status table 630 generated by 
data structure 515a includes a respective entry (of entries the CMM 250 of the P^sent invention each time a local bus 
531fl-531n) for each of the n devices coupled to the local on rese f is , generated. The GUID status table 630 includes 
bus 30. Tbe first field 532 of each entry corresponds to the 20 cntne ? M*481g « gardmg (1) which devices remain con- 
device's physical identifier as assigned by the local buslayer reeled to the l^albus 30 since the last GUID list 510 was 
330. As shown in FIG. 9B, tte entries 531a-531* are £° mpde ^ afte ; a ^ ' buS teset (2) which devices have 

, , ,. * ii_ • i_ ■ , .j i_ • i been just removed and (3) which devices have been just 

ordered according^ their physical identifier e.g physical. added J since me last GUir } ]k 510 was compiled. A first field 

ID0, physicaUDl, . . . , physicaLJDn. Field 534 indicates 25 632 represcnts mc GUID value of ^ dcvicc ^ an asso . 

information pertinent to the communication protocol ciated field 634 repr esents the current status of that device, 

(including communicate rate) available for the device. FIGt 12A represents an exemplary table 630 generated by 

Speed map 515a data structures of the format shown m FIG. CMM 250 as a result of the exemplary configurations of 

9B are well known in the art and are re-generated upon each FIG. 10A and FIG. 10B. As shown in table 630, the devices 

local bus reset. 30 having GUID(Y), GUID(X), GUID(Z), and GUID(J) remain 

FIG. 9C illustrates a two dimensional speed map 5156 after the local bus reset. However, the devices having 

data structure used by the present invention. Speed map GUID(U), and GUID(N) have been added after the local bus 

5156 is a matrix where each matrix entry 546 conveys reset and the device having GUID(I) was removed after the 

information regarding the communication speed between local bus reset. In one embodiment, the GUID table 630 is 

referenced devices (e.g., devices referenced by phy__id n 35 compiled by the CMM 250 and stored in computer readable 

and phy_id 2). The speed map 5156 has a first index 542 memory. 

and a second index 544, both being ordered according to FIG. 12B illustrates a subset status table 650 generated by 

their physical identifiers. Speed map 5156 data structures of the CMM 250 which contains entries 652a-6526 indicating 

the format shown in FIG. 9C are well known in the art and only which devices have been added to the local bus 30 since 

are re-generated upon each local bus reset, 40 the last GUID list 510 was compiled. Likewise, FIG. 12C 

FIG. 10A illustrates an exemplary HAVI network 560a illustrates a subset status table 660 generated by the CMM 

having five devices coupled to the local bus. Device 562 has 250 which contains entries (662a) indicating only which 

a physical identifier (0) and a GUID(Y); device 564 has a devices have been removed from the local bus 30 since the 

physical identifier (1) and a GUID(Z); device 566 has a last GUID list 510 was compiled. In one embodiment, the 

physical identifier (2) and a GUID(I); device 568 has a 45 GUID tables 650-660 are compiled by the CMM 250 and 

physical identifier (3) and a GUID(J) and device 570 has a stored in computer readable memory. Device status tables 

physical identifier (4) and a GUID(X). Each of the GUID 630, 650 and 660 are forwarded to objects within the HAVI 

values is unique and persistent. The physical identifier architecture that establish callback handlers within the 

values for the devices of FIG. 10A can become reassigned CMM 250 to receive this information, 

after a local bus reset. 50 FIG. 13 illustrates a flow diagram 700 of the steps 

FIG. 11A illustrates the resulting GUID list 510a com- performed by the link driver 320 of the present invention for 

piled by the present invention based on the exemplary HAVI compiling a current GUID table 510 in response to a local 

network 560a of FIG. 10A. The GUID list 510a contains bus reset. After a local bus reset, physical identifiers of 

five entries, one for each device of the HAVI network. As devices are reassigned by the local bus 30. At step 710, if a 

shown, the GUID values in the GUID list 510a are ordered, 55 local bus reset is reported to the link driver 320, then step 

e.g., GUID(Y); GUID(Z); GUID(I); GUID(J); and GUID 715 is entered. At step 715, current GUID list is erased and 

(X), according to the corresponding physical identification the link driver 320 determines the number of devices, n, that 

values, 0, 1, 2, 3 and 4, respectively. In one embodiment, are currently coupled to the local bus 30. A number of well 

GUID list 510a is compiled by the link driver 320 and stored known mechanisms can be used to implement step 715. At 

in computer readable memory. <>o step 720, a counter is set to zero. At step 725, the link layer 

FIG. 10B illustrates another exemplary HAVI network 320 issues a request to the device coupled to the local bus 30 

5606 having six devices coupled to the local bus. Network and having the physical identifier corresponding to the 

5606 is similar to network 560a except device 566 is counter value. The request is for the GUID value of this 

removed and devices 572 and 574 are added. In network device. At this point, the link layer 320 is unaware which 

5606, device 572 has a physical identifier (1) and a GUID 65 device this is. 

(U) and device 574 has a physical identifier (5) and a At step 730, the fink layer 320 receives the return GUID 

GUID(N). Some of the physical identifier values between value from the device with the physical identifier of the 
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counter value and places this GUID value into a next entry At step 910, an application layer issues a command to 

of the current GUID list 510 (the entry position also corre- determine the communication speed supported between 

sponds to the counter value). At step 735, the counter is device(x) and device(y). The request includes the GUID 

incremented by one. At step 740, a check is made if the values for device(x) and device(y). At step 915, the CMM 

counter is equal to n (the maximum number of devices on 5 250 receives this command and the GUID values. The CMM 

the local bus). If not, then step 725 is entered again to 250 translates the GUID values into two physical identifiers 

continue compiling the current GUID list. If so, then at step based on the index of the GUIDs within the GUID list 510. 

745, the link layer 320 forwards the CMM 250 a copy of the At step 920, the CMM 250 then accesses (e.g., indexes) a 

current GUID list 510. It is appreciated that physical iden- two dimensional speed map data structure 515£» with the 

tifiers are assigned by the local bus 30 from 0 to (n-1) obtained two physical identifiers. The speed map thereby 

values. After process 700, a current GUID list 510 like those returns the proper speed information. At step 925, the CMM 

shown in FIG. 11A and FIG. 11B is compiled. 250 forwards the determined speed information to the 

FIG. 14 illustrates a flow diagram 800 of the steps requesting application layer, 

performed by the Link layer 320 and the CMM 250 of the FIG. 15C illustrates a flow diagram 950a of steps per- 

present invention for compiling the device status tables 630, ]5 formed by the present invention for accessing topology map 

650, 660 in response to a local bus reset. As discussed above, information with respect to a device given its GUID value, 

process 700 generates a current GUID list 510 in response At step 955, an application layer issues a command to 

to a local bus reset and passes the current list to the CMM determine the topology of a device(y). The request includes 

250. At step 820, the current GUID list is received and the the GUID value for device(y). At step 960, the CMM 250 

last GUID list received by the CMM 250 is retained and 20 receives this command and the GUID value. The CMM 250 

marked as a "previous" GUID list. At step 825, the CMM translates the GUID value into a physical identifier based on 

250 compares the entries of the previous GUID list and the the index of the GUID within the GUID list 510. At step 965, 

current GUID list 510 and generates GUID table 650 based the CMM 250 then accesses (e.g., indexes) a topology data 

on the new GUID values that are present in the current structure 520 with the obtained physical identifier. The 

GUID list 510 but not in the previous GUID list. Any object ^5 topology map thereby returns the proper topology informa- 

within the HAVI architecture that previously established a tion for device(y). At step 970, the CMM 250 forwards the 

callback handler with the Event Manager 214 for the infer- determined topology information to the requesting applica- 

mation of table 650 is sent a message including the status tion layer. 

information of table 650. FIG. 15D illustrates a flow diagram 900/? of steps per- 

At step 830, the CMM 250 compares the entries of the 30 formed by the present invention for accessing speed map 

previous GUID list and the current GUID list 510 and information with respect to two devices given their GUIDs. 

generates GUID table 660 based on any GUID values that The difference between process 900d and 900a (FIG. 15A) 

are no longer present in the current GUID list 510 but were is that the application program determines the speed 

present in the previous GUID list. Any object within the information, not the CMM 250. At step 980, an application 

HAVI architecture that previously established a callback 35 layer issues a command to determine the communication 

handler with the Event Manager 214 for the information of speed between device(x) and device(y). At step 982, the 

table 660 is sent a message including the status information CMM 250 receives this command and forwards the current 

of table 660. Optionally, at step 830, the information from GUID list 510 as well as a copy of the speed map 5156 (or 

tables 660 and 650 can be combined with the GUID values pointers to these data structures) to the application program, 

that are common to both the previous and current GUID lists 40 At step 984, the application program translates the GUID 

thereby generating table 630. At step 835, the CMM 250 values of the two devices into two physical identifiers based 

erases the previous GUID list and uses only the current on the index of the GUIDs within the GUID list 510. The 

GUID list 510. By performing process 800, the CMM 250 application program then accesses (e.g., indexes) the two 

and the link layer 320 of the present invention eliminate the dimensional speed map data structure SISb with the 

burden from higher level application programs of tracking 45 obtained two physical identifiers. The speed map thereby 

which devices are on the local bus while providing the high returns the proper speed information, 

level application programs with device status information. FIG. 15E illustrates a flow diagram 950b of steps per- 

FTG. 15A illustrates a flow diagram 850 of steps per- formed by the present invention for accessing topology 

formed by the present invention for translating GUID values information with respect to a device given its GUID. The 

into physical identifications using the GUID list 510 passed 50 difference between process 950b and 950a (FIG. 15B) is that 

to the CMM 250. At step 855, an application program issues the application program determines the topology 

a command to control a device(x) and this command is information, not the CMM 250. At step 990, an application 

received by the DCM of the device(x). At step 860, the DCM layer issues a command to determine the topology informa- 

issues a command to the CMM 250 including device(x)*s tion of device(y). At step 992, the CMM 250 receives this 

GUID value which is known to the DCM. At step 865, the 55 command and forwards the current GUID list 510 as well as 

CMM 250 determines the index (e.g., entry order) of the a copy of the topology map 520 (or a pointer to this data 

device(x)'s GUID within the GUID list 510. This value is structure) to the application program. At step 994, the 

the physical identifier of device(x). At step 870, the CMM application program translates the GUID value of the device 

250 issues a command to the link driver layer 320 including (y) into a physical identifier based on the index of the GUID 

device(x)'s physical identifier and an action command. The 60 within the GUID list 510. The application program then 

link driver layer 320 then commands device(x) using the accesses (e.g., indexes) the topology data structure 520 with 

received physical identifier. Using process 850, high level the obtained physical identifier. The topology map thereby 

applications do not need to be aware of a device's physical returns the proper topology information, 

identifier but can use the constant GUID value. It is appreciated that by providing the GUID list 510, the 

FIG. 15B illustrates a flow diagram 900a of steps per- 65 present invention allows high level applications to utilize 

formed by the present invention for accessing speed map persistent device identifiers (GUIDs) to references devices, 

information with respect to two devices given their GUIDs. Upon a bus reset, the high level devices are not burdened 



03/26/2004, EAST Version: 1.4.1 



6,038,625 



27 



28 



with the reassignments of physical identifiers that are done 
at the local bus level. The GUID list 510 is particularly 
efficient by organizing the ordering of GUIDs to conform to 
the physical identifier value. This reduces memory required 
to store the GUID list 510 and creates an efficient index 
mechanism. 

The preferred embodiments of the present invention, a 
method and system for providing efficient device identifi- 
cation using a GUID list within a consumer electronics 
based audio/video network, are thus described. While the 
present invention has been described in particular 
embodiments, it should be appreciated that the present 
invention should not be construed as limited by such 
embodiments, but rather construed according to the below 
claims. 

What is claimed is: 

1. A method of providing device identification to access 
information within a network, said method comprising the 
steps of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID identifies a unique device of said 
network and wherein said constructing orders GUIDs 
within said list of GUIDs according to their associated 
physical identifier values, wherein said physical iden- 
tifier values are assigned by a local bus of said network; 

b) receiving a request originating from an application 
program to determine a communication speed value 
corresponding to a device of said network wherein said 
request includes a first GUID corresponding to said 
device; 

c) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a speed map data structure with said first 
index value to obtain said communication speed value, 
wherein said speed map data structure is organized 
based on physical identifiers. 

2. A method as described in claim 1 further comprising the 
step of e) communicating said communication speed value 
to said application program and wherein said network is a 
network of the home audio/visual initiative (HAVI) archi- 
tecture and wherein said local bus is of the IEEE 1394 
standard. 

3. A method as described in claim 1 further comprising the 
steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said speed map data structure based on 
renumbered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

4. A method as described in claim 1 wherein each GUID 
is a persistent multi-bit value comprising a vendor code 
portion and a chip series code portion. 

5. A method as described in claim 1 wherein said step a) 
is performed in response to a local bus reset and comprises 
the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 
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a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

6. A method of providing device identification to access 
information within a network, said method comprising the 
steps of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID identifies a unique device of said 
network and wherein said constructing orders GUIDs 
within said list of GUIDs according to their associated 
physical identifier values, wherein said physical iden- 
tifier values are assigned by a local bus of said network; 

b) receiving a request originating from an application 
program to determine topology information corre- 
sponding to a device of said network wherein said 
request includes a first GUID corresponding to said 
device; 

c) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a topology map data structure with said 
first index value to obtain said topology information, 
wherein said topology map data structure is organized 
based on physical identifiers. 

7. A method as described in claim 6 further comprising the 
step of e) communicating said topology information to said 
application program and wherein said network is a network 
of the home audio/visual initiative (HAVI) architecture and 
wherein said local bus is of the IEEE 1394 standard. 

8. A method as described in claim 6 further comprising the 
steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said topology map data structure based on 
renumbered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f), 

9. A method as described in claim 6 wherein each GUID 
is a persistent multi-bit value comprising a vendor code 
portion and a chip series code portion. 

10. A method as described in claim 6 wherein said step a) 
is performed in response to a local bus reset and comprises 
the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

11. A method of providing device identification within a 
network, said method comprising the steps of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID is persistent and identifies a unique 
device of said network and wherein said constructing 
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orders GUIDs within said list of GUIDs according to 
their associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an application 
program to communicate with a device of said network 
wherein said request includes an identifier correspond- 
ing to said device; 

c) translating said identifier into a first GUID correspond- 
ing to said device; 

d) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs wherein said first index value is a 
first physical identifier; and 

e) issuing a communication to said device over said local 
bus using said first physical identifier, wherein said 
communication corresponds to said application pro- 
gram request. 

12. A method as described in claim 11 wherein said 
network is a network of the home audio/visual initiative 
(HAVI) architecture and wherein said local bus is of the 
IEEE 1394 standard. 

13. A method as described in claim 11 further comprising 
the steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; and 

g) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

14. A method as described in claim 11 wherein each 
GUID is a multi-bit value comprising a vendor code portion 
and a chip series code portion. 

15. A method as described in claim 11 wherein said step 
a) is performed in response to a local bus reset and com- 
prises the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into a computer readable 
memory unit. 

16. An electronic system having a processor, an internal 
bus and a computer readable memory unit, said system 
coupled to an IEEE 1394 local bus, wherein said memory 
unit having instructions stored therein that implement a 
method of providing device identification to access infor- 
mation within a network, said method comprising the steps 
of: 

a) constructing a list of global unique identifiers (GUIDs) 
wherein each GUID is persistent and identifies a unique 
device of said network and wherein said constructing 
orders GUIDs within said list of GUIDs according to 
their associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) receiving a request originating from an application 
program to determine information corresponding to a 
device of said network wherein said request includes a 
first GUID corresponding to said device; 
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c) using said list of GUIDs to determine a first index value 
corresponding to a position of said first GUID within 
said list of GUIDs; and 

d) referencing a map data structure with said first index 
value to obtain said information wherein said map data 
structure is organized based on physical identifiers. 

17. An electronic system as described in claim 16 wherein 
said method further comprises the step of e) communicating 
said information to said application program and wherein 
said network is a network of the home audio/visual initiative 
(HAVI) architecture and wherein said local bus is of the 
IEEE 1394 standard. 

18. An electronic system as described in claim 16 wherein 
said method further comprises the steps of: 

f) in response to a local bus reset, renumbering physical 
identifiers of devices of said network that are coupled 
to said local bus; 

g) rebuilding said map data structure based on renum- 
bered physical identifiers of step f); and 

h) constructing a new list of GUIDs based on said 
renumbered physical identifiers of step f). 

19. An electronic system as described in claim 16 wherein 
each GUID is a multi-bit value comprising a vendor code 
portion and a chip series code portion. 

20. An electronic system as described in claim 16 wherein 
said step a) of said method is performed in response to a 
local bus reset and comprises the steps of: 

al) receiving from said local bus an indication of the 
number of devices of said local bus; 

a2) starting with physical identifier zero and incrementing 
to a last physical identifier corresponding to said num- 
ber of devices of said local bus, forwarding requests to 
said devices of said local bus individually requesting 
their GUIDs; 

a3) recording into said list of GUIDs any GUIDs returned 
from said devices of said local bus, said GUIDs 
recorded into positions said list of GUIDs based on 
their corresponding physical identifier values; and 

a4) storing said list of GUIDs into said computer readable 
memory unit. 

21. An apparatus for providing device identification to 
access information within a network, said apparatus com- 
prising: 

a) means for constructing a list of global unique identifiers 
(GUIDs), wherein each GUID is persistent and identi- 
fies a unique device of said network, by ordering 
GUIDs within said list of GUIDs according to their 
associated physical identifier values, wherein said 
physical identifier values are assigned by a local bus of 
said network; 

b) means for receiving a request originating from an 
application program to determine information corre- 
sponding to a device of said network wherein said 
request includes a first GUID corresponding to said 
device; 

c) means for using said list of GUIDs to determine a first 
index value corresponding to a position of said first 
GUID within said list of GUIDs; and 
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d) means for referencing a map data structure with said 
first index value to obtain said information wherein said 
map data structure is organized based on physical 
identifiers. 

22. An apparatus as described in claim 21 wherein said s 
means for constructing is responsive to a local bus reset and 
comprises: 

al) means for receiving from said local bus an indication 
of the number of devices of said local bus; 

a2) means for starting with physical identifier zero and 10 
incrementing to a last physical identifier corresponding 
to said number of devices of said local bus, forwarding 
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requests to said devices of said local bus individually 
requesting their GUIDs; 
a3) means for recording into said list of GUIDs any 
GUIDs returned from said devices of said local bus, 
said GUIDs recorded into positions said list of GUIDs 
based on their corresponding physical identifier values; 
and 

a4) means for storing said list of GUIDs into said com- 
puter readable memory unit. 
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